Trust establishment to deploy servers in data centers

ABSTRACT

In one example, a system is disclosed, which may include a network device, a new server connected to the network device, and a management server communicatively connected to a cloud-based service and the network device. The management server may include a server deployment engine to discover the new server in the system using the network device, obtain an encrypted data blob associated with the new server from the cloud-based service, establish a trust, via a secure protocol, with the new server using the encrypted data blob, and deploy the new server in the system upon establishing the trust with the new server.

BACKGROUND

Many organizations may utilize data centers to provide centralizedcomputational and/or storage services. Data centers may provide afacility that may be used to run the computer-based applications thathandle the core business and operational data of organizations. Datacenters may host large numbers of network servers, storage devices,network switches and other equipment.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples are described in the following detailed description and inreference to the drawings, in which:

FIG. 1A is a block diagram of an example system, in which a new servercan be deployed;

FIG. 1B is a block diagram of the example system of FIG. 1, depicting adatacenter in which the new server can be deployed;

FIG. 2 is a block diagram illustrating additional components of theexample system of FIGS. 1A and 1B;

FIGS. 3 and 4 depict example flow charts for establishing a secure trustand deploying a new server in a data center; and

FIGS. 5 and 6 depict example block diagrams showing a non-transitorycomputer-readable media for establishing a secure trust and deploying anew server in a data center.

DETAILED DESCRIPTION

In order to deploy/provision a new server in a data center, a datacenter administrator may manually read a password and server credentials(e.g., a serial number and unique identifier) shipped as part of the newserver and then provision the new server in the data center using thepassword and server credentials via a management engine in a managementserver. For example, the password and the new server credentials may befed to a home grown database, may be used in a script as input or may beprovided as input to management engines for adding the new server. Inexisting methods, a customer may opt for custom to order/factory expresssolution to configure a default password for the new servers or thevendor may ship the servers with a default password. Existing methodsmay be insecure, add cost due to custom to order/factory expressprocess, and/or error prone due to manual process.

Examples described herein may establish a trust between a new server(e.g., bare metal server) shipped from factory and a server deploymentmodule in a management server using a cloud-based service and a secureprotocol. Example server may include a rack server, tower server, andother devices in the data center. Further, examples described herein mayenable automation of the new server deployment in the data center uponestablishing the trust between the new server and the server deploymentengine.

In one example, the server deployment engine may discover the new serveradded in the data center using a network device connected to the newserver. The server deployment engine may establish a trusted connectionwith the cloud-based service using a trusted certificate. The serverdeployment engine may obtain an encrypted signed data blob associatedwith the new server from the cloud-based service upon establishing thetrusted connection. The encrypted signed data blob may include theencrypted data blob that may be signed by the cloud-based service usinga cloud-based service private key.

In one example, during manufacturing process of the new server, datablob may be encrypted using new server's own public key. Further, thenew server may return the encrypted data blob for storing in thecloud-based service. Upon establishing the trusted connection,cloud-based service may sign the encrypted data blob and send theencrypted signed data blob to management server. The encrypted data blobmay include a password and device credentials associated with the newserver. Example device credentials may include a unique identifier, arandom number or a combination thereof. The server deployment engine maysend the encrypted signed data blob to the new server.

Further, the new server may include an authentication engine to receivethe encrypted signed data blob from the server deployment engine. Theauthentication engine may verify signature of the encrypted signed datablob using a corresponding cloud-based service public key shipped withthe new server. The authentication engine may decrypt the encrypted datablob using a private key shipped with the new server upon verifying thesignature of the encrypted signed data blob. The authentication enginemay determine that the decrypted data blob includes default password anddevice credentials associated with the new server. The authenticationengine may enable the server deployment engine to establish the trustwith the new server based on the determination.

Furthermore, the server deployment engine may establish the trust, via asecure protocol, with the new server in response to the new serverauthenticating the encrypted signed data blob. The server deploymentengine may deploy the new server in the data center based on pre-definedrules (e.g., customer-defined rules) upon establishing the trust withthe new server. In one example, the server deployment engine may send aonetime password to the new server upon establishing the trust with thenew server, the onetime password may be used to login and deploy the newserver.

Examples described herein may enable a policy based automation of thenew server deployment in a secure way. Examples described herein mayeliminate the need for manual intervention like reading and updatingmanagement applications with the information present in the new server.Examples described herein may improve the customer experience forautomating registration of new servers in data centers.

The terms “deploy” and “provision” may be interchangeably usedthroughout the document and may refer to a process of installingsoftware and/or hardware on a new server (i.e., bare metal servershipped from factory).

FIG. 1A is a block diagram of an example system 100, in which a newserver 110 can be deployed. System 100 may include a network device 108,new server 110 connected (e.g., plugged in) to network device 108, and amanagement server 106 communicatively connected to network device 108.For example, the system may be included within a data center, system mayrepresent a single data center, and/or the data center may or may notinclude a cloud-based service. Management server 106 may include aserver deployment engine 112 to automate provisioning of new server 110in system 100. Example system 100 may be explained in detail in FIG. 1B.

FIG. 1B is a block diagram of the example system 100 depicting a datacenter 104 in which the new server 110 can be deployed. System 100 mayinclude a cloud-based service 102 and data center 104. Cloud-basedservice 102 may be a service that is available to management server 106on demand via a network connection. Cloud-based service 102 may storeencrypted data blob associated with the new server or may retrieveencrypted data blobs from a centralized storage server. In one example,the encryption of the data blobs may be performed using the server's ownpublic key that could be generated during the manufacturing process ofnew server 110. Further during the manufacturing process, new server 110may return the encrypted data blob for storing in cloud-based service102 or send the encrypted data blob to a centralized storage server forlater access.

Data center 104 may include a network device 108, new server 110connected (e.g., plugged in) to network device 108, and a managementserver 106 communicatively connected to cloud-based service 102 andnetwork device 108. In the example shown in FIG. 1B, data center 104 maybe described using one network device and one server, however, datacenter 104 can include any number of network devices and servers, forexample, as shown in FIG. 2.

Management server 106 may include a server deployment engine 112 toautomate provisioning of new server 110 in data center 104. Serverdeployment engine 112 may discover new server 110 in data center 104,for instance, when new server 110 is connected/plugged into networkdevice 108. For example, server deployment engine 112 may discover newserver 110 that is added to data center 104 using a newly leased dynamichost configuration protocol (DHCP) addresses or upon receiving arequest, for instance, from a network administrator. Server deploymentengine 112 may obtain unique identifier (e.g., serial number,universally unique identifier, and the like) associated with new server110 using link layer discovery protocol (LLDP) or using a hypertexttransfer protocol secure (HTTPS) unauthenticated call that can provideunique identifiers of the new server.

Server deployment engine 112 may establish a trusted connection withcloud-based service 102 using a trusted certificate. In one example,cloud-based service 102 may authenticate server deployment engine 112using the trusted certificate and then enable to establish the trustedconnection. This may be explained in detail in FIG. 2.

Server deployment engine 112 may obtain/download the encrypted data blobassociated with new server 110 from cloud-based service 102 uponestablishing the trusted connection. The encrypted data blob may includea password and device credentials associated with new server 110.Example device credentials may include a unique identifier, a randomnumber or a combination thereof. In another example, server deploymentengine 112 may obtain an encrypted signed data blob from cloud-basedservice 102 in a secure way using the unique identifier associated withnew server 110. The encrypted signed data blob may include the encrypteddata blob that may be signed by cloud-based service 102 using acloud-based service private key. Encrypted signed data blob may alsoinclude authenticated server deployment engine identifiers.

In one example, new server 110 shipped from factory may have aprivate/public key pair. In factory mode, new server 110 may retrieve adata blob with the default password and unique identifiers like serverserial number/universally unique identifier. The retrieved data blob maybe encrypted using new server specific public key such that new server110 with the corresponding private key can decrypt the encrypted datablob. During the manufacturing process, new server 110 may return theencrypted data blob for storing in cloud-based service 102. Cloud-basedservice 102 may expose the encrypted data blob in a secure way tomanagement servers. Further, cloud-based service 102 may authenticate amanagement server (e.g., 106) using a trusted certificate associatedwith management server 106. Upon authenticating management server 106,cloud-based service 102 may sign the encrypted data blob using thecloud-based service owned private key and then return the encryptedsigned data blob to management server 106.

In one implementation, the cloud-based service may sign the encrypteddata blob at the time of request using the private key that is securedusing a key management appliance. The cloud-based service may usesigning algorithms such as Rivest-Shamir-Adleman (RSA) algorithm withkey length>=3072, secure hash algorithm (SHA) 256 or greater hashingalgorithm, to sign the encrypted data blob. The encrypted signed datablob may include the encrypted data blob (i.e., stored during thefactory process) and the authenticated management server identifierssuch as public key and the name of the server.

Server deployment engine 112 may send the encrypted signed data blob tonew server 110. For example, server deployment engine 112 may send theencrypted signed data blob to new server 110 using the LLDP packets overa network interface. Management server 106 and new server 110 mayexchange communications via LLDP packets to establish the trust in asecure way. The communications between management server 106 and newserver 110 may be encrypted using public key/private key pair associatedwith the management server 106 and the new server 110.

Furthermore, server deployment engine 112 may establish the trust, via asecure protocol, with new server 110 upon authenticating the encryptedsigned data blob by new server 110. Secure protocol may provide a securecommunication between management server 106 and new server 110 over acomputer network which can be used on the Internet/Intranet. Examplesecure protocol may include Hyper Text Transfer Protocol Secure (HTTPS).

Authenticating the encrypted signed data blob by new server 110 isexplained in FIG. 2. Server deployment engine 112 may deploy/provisionnew server 110 in data center 104 upon establishing the trust with newserver 110. In one example, server deployment engine 112 may send aonetime password to new server 110 upon establishing the trust with newserver 110, the onetime password may be used to login and deploy newserver 110. In one example, the onetime password may be sent using LLDPprotocol. Server deployment engine 112 may deploy new server 110 in datacenter 104 based on pre-defined rules (e.g., customer-defined rules)based on configured IP address ranges.

FIG. 2 is a block diagram illustrating additional components of theexample system 100 of FIGS. 1A and 1B. In the example shown in FIG. 2,Data center 104 may include multiple network devices 108A-N and servers110 and 206A-N connected (e.g., plugged in) to corresponding networkdevices 108A-N. Management server 106 may include server deploymentengine 112 to manage multiple servers 110 and 206A-N in data center 104.For example, server 110 may be the newly added server in data center 104and servers 206A-N may be servers that are operating in data center 104.

Server deployment engine 112 may obtain the encrypted signed data blobassociated with new server (e.g., new server 110) from cloud-basedservice 102. In one example, cloud-based service 102 may include anauthentication engine 204 to receive a request for encrypted data blobfrom server deployment engine 112 and authenticate the trustedcertificate associated with server deployment engine 112. In response toauthenticating server deployment engine 112, authentication engine 204may sign the encrypted data blob using a cloud-based service private keyand send the encrypted signed data blob to server deployment engine 112.Server deployment engine 112 may then send the encrypted signed datablob to new server 110.

Further, new server 110 may include an authentication engine 202 toreceive the encrypted signed data blob from server deployment engine112. Authentication engine 202 may verify signature of the encryptedsigned data blob using a corresponding cloud-based service public keyshipped with new server 110. For example, authentication engine 202 mayverify signature of the encrypted signed data blob to authenticate thecloud-based service 102. Authentication engine 202 may decrypt theencrypted signed data blob using a private key in new server 110 uponverifying the signature of the encrypted signed data blob.Authentication engine 202 may determine that the decrypted data blobincludes default password and device credentials associated with newserver 110. For example, authentication engine 202 may compare thedefault password and device credentials in the decrypted data blob withdefault password and device credentials shipped with new server 110.Authentication engine 202 may enable server deployment engine 112 toestablish the trust with new server 110 when the default password anddevice credentials in the decrypted data blob matches with defaultpassword and device credentials shipped with new server 110.

once the trust is established, the LLDP encryption may happen usingpublic keys that are exchanged through LLDP packets or when the publickey of the management server 106 is signed by the cloud-based serviceand sent back in the encrypted data blob to the new server 110, the newserver 110 can start trusting the communication from the managementserver 106 with the corresponding public key. For example,authentication engine 202 may determine that the encrypted signed datablob may be sent by a valid server deployment engine (e.g., 112), andthen start sending encrypted LLDP packets over the network interfaceusing the management server public key. Authentication engine 202 mayalso set a flag to accept LLDP packets from the authenticated serverdeployment engine and a onetime password. Once the trust is established,server deployment engine 112 may send a onetime password for next loginthat can be used to login to the new server 110 and set up/configure newserver 110.

In another example, server deployment engine 112 may receive a nonce(e.g., a random number) from new server 110 using link layer discoveryprotocol (LLDP) packets, send the nonce to cloud-based service 102,obtain a signed nonce along with the encrypted data blob fromcloud-based service 102, send the signed nonce along with the encrypteddata blob to new server 110, and establish the trust between managementserver 106 and new server 110 upon successful authentication of thesigned nonce and the encrypted data blob by new server 110.

In one example, the components of system 100 may be implemented inhardware, machine-readable instructions or a combination thereof. In oneexample, each of server deployment engine 112 and authentication engines202 and 204 can be any combination of hardware and programming toimplement the functionalities described herein. In another example, thefunctionality of the components of system 100 may be implemented usingtechnology related to personal computers (PCs), server computers, tabletcomputers, mobile computers and the like.

FIGS. 1-2 show a system 100 to deploy a server in data center 104.System 100 may include computer-readable storage medium comprising(e.g., encoded with) instructions executable by a processor to implementfunctionalities described herein in relation to FIGS. 1-2. In someexamples, the functionalities described herein in relation toinstructions to implement functions of server deployment engine 112 andauthentication engines 202 and 204 and any additional instructionsdescribed herein in relation to storage medium, may be implemented asengines or modules comprising any combination of hardware andprogramming to implement the functionalities of the modules or engines,as described below. The functions of server deployment engine 112 andauthentication engines 202 and 204 may be implemented by computingdevices which may be servers, blade enclosures, desktop computers,laptops (or notebooks) computers, workstations, tablet computers, mobilephones, smart devices, or any other processing devices or equipmentincluding a processing resource. In examples described herein, aprocessor may include, for example, one processor or multiple processorsincluded in a single computing device or distributed across multiplecomputing devices.

FIGS. 3 and 4 depict example flow charts for establishing a secure trustand deploying a new server in a data center. Particularly, FIG. 3depicts an example flow chart 300 of a process for automation of serverdeployment implemented on a management server. It should be understoodthe process depicted in FIGS. 3 and 4 represents generalizedillustrations, and that other processes may be added or existingprocesses may be removed, modified, or rearranged without departing fromthe scope and spirit of the present application. In addition, it shouldbe understood that the processes may represent instructions stored on acomputer-readable storage medium that, when executed, may cause aprocessor to respond, to perform actions, to change states, and/or tomake decisions. Alternatively, the processes may represent functionsand/or actions performed by functionally equivalent circuits like analogcircuits, digital signal processing circuits, application specificintegrated circuits (ASICs), or other hardware components associatedwith the system. Furthermore, the flow charts are not intended to limitthe implementation of the present application, but rather the flowcharts illustrate functional information to design/fabricate circuits,generate machine-readable instructions, or use a combination of hardwareand machine-readable instructions to perform the illustrated processes.

At 302, a new server added to a data center may be discovered via anetwork device connected to the new server, for instance, by amanagement server. At 304, a trusted connection may be established witha cloud-based service using a trusted certificate. At 306, an encryptedsigned data blob associated with the new server may be obtained from thecloud-based service upon establishing the trusted connection.

In one example, the encrypted signed data blob associated with the newserver may be obtained from the cloud-based service using a uniqueidentifier associated with the new server. The encrypted signed datablob may include an encrypted data blob signed by the cloud-basedservice using a cloud-based service private key. The encrypted data blobmay include a password and device credentials associated with the newserver and the public key of the authenticated management server.Example device credentials may include a unique identifier, a randomnumber or a combination thereof.

At 308, the encrypted signed data blob may be sent to the new server. At310, a trust may be established with the new server upon authenticatingthe encrypted signed data blob by the new server. Authenticating theencrypted signed data blob by the new server may be explained in FIG. 4.In one example, in establishing the trust between the management serverand the new server, the communications between the management server andthe new server may be carried out using link layer discovery protocol(LLDP) packets. In one example, the LLDP packets may be retrieved usingthe network switch and communicated via the network switch connectingthe new server and the management server. For example, the managementserver can login to the network device (e.g., network switch) andretrieve the LLDP packets that may be sent by the new server to thenetwork device.

At 312, the new server may be deployed in the data center uponestablishing the trust with the new server. In one example, a onetimepassword may be sent to the new server, which can be used to login tothe new server to set up the new server.

FIG. 4 depicts an example flow chart 400 of a process for authenticatingthe encrypted signed data blob implemented on the new server. At 402,the encrypted signed data blob may be received from the managementserver by the new server. At 404, signature of the encrypted signed datablob may be verified using a corresponding cloud-based service publickey shipped with the new server. At 406, the encrypted data blob may bedecrypted using a private key in the new server upon verifying thesignature of the encrypted signed data blob. At 408, a check may be madeto determine that the decrypted data blob may include default passwordand device credentials associated with the new server. At 410, the trustmay be established between the management server and the new serverbased on the determination. In one example, the new server may start toaccept requests via LLDP packets sent from the management server via thenetwork switch.

The processes 300 and 400 of FIGS. 3 and 4 may show example processesand it should be understood that other configurations can be employed topractice the techniques of the present application. For example,processes 300 and 400 may communicate with a plurality of computingdevices and the like.

FIGS. 5 and 6 are example block diagrams 500 and 600 showing anon-transitory computer-readable media that stores code for operation inaccordance with an example of the techniques of the present application.Particularly FIG. 5 illustrates management server side implementation ofautomation process for server deployment and FIG. 6 illustrates newserver side implementation of automation process for server deployment.Non-transitory computer-readable media includes a machine readablestorage medium 506 on management server 502 side and machine readablestorage medium 606 on new server 602 side. Non-transitorycomputer-readable media may be generally referred to by the referencenumbers 506 and 606 and may be included in a computing system, such asmanagement server 502 and/or new server 602, respectively.Non-transitory computer-readable media 506 and 606 may correspond to anystorage device that stores computer-implemented instructions, such asprogramming code or the like. For example, non-transitorycomputer-readable media 506 and 606 may include non-volatile memory,volatile memory, and/or storage devices. Examples of non-volatile memoryinclude, but are not limited to, electrically erasable programmable ReadOnly Memory (EEPROM) and Read Only Memory (ROM). Examples of volatilememory include, but are not limited to, Static Random Access Memory(SRAM), and dynamic Random Access Memory (DRAM). Examples of storagedevices include, but are not limited to, hard disk drives, compact discdrives, digital versatile disc drives, optical drives, and flash memorydevices.

Processors 504 and 604 generally retrieve and execute the instructionsstored in non-transitory computer-readable media 506 and 606respectively, to operate the present techniques in accordance with anexample. In one example, the tangible, computer-readable media 506 and606 can be accessed by the respective one of processors 504 and 604 overa bus.

Machine-readable storage media 506 may store instructions 508-518. In anexample, instructions 508-518 may be executed by processor 504 oncomputing device/management server 502 to provide a mechanism formanagement server side implementation of automation process.Instructions 508 may be executed by processor 504 to receive a requestto deploy a new server. Instructions 510 may be executed by processor504 to establish a trusted connection with a cloud-based service using atrusted certificate. Instructions 512 may be executed by processor 504to obtain an encrypted signed data blob associated with the new serverfrom the cloud-based service upon establishing the trusted connection.The encrypted signed data blob may include a password and devicecredentials (e.g., serial number, random number, and the like)associated with the new server. Instructions 514 may be executed byprocessor 504 to send the encrypted signed data blob to the new server.Instructions 516 may be executed by processor 504 to establish a trustwith the new server based on successful authentication of the encryptedsigned data blob by the new server. Instructions 518 may be executed byprocessor 504 to send a onetime password to the new server uponestablishing the trust with the new server, the onetime password may beused to login and deploy the new server.

Machine-readable storage media 606 may store instructions 608-616. In anexample, instructions 608-616 may be executed by processor 604 on theserver 602 to provide a mechanism for new server side implementation ofthe automation process. Instructions 608 may be executed by processor604 to receive the encrypted signed data blob from the managementserver. Instructions 610 may be executed by processor 604 to verifysignature of the encrypted signed data blob using a correspondingcloud-based service public key shipped with the new server. Instructions612 may be executed by processor 604 to decrypt the encrypted data blobusing a private key shipped with the new server upon verifying signatureof the encrypted signed data blob. Instructions 614 may be executed byprocessor 604 to determine that the decrypted data blob includes defaultpassword and device credentials associated with the new server.Instructions 616 may be executed by processor 604 to establish the trustbetween the management server and the new server based on thedetermination. Upon establishing the trust, the management server maydeploy the new server in the data center using the onetime password.

In another example, machine-readable storage media 506 may includeinstructions to receive a nonce (e.g., a random number) from the newserver in link layer discovery protocol (LLDP) packets, send the nonceto the cloud-based service, obtain a signed nonce along with theencrypted data blob from the cloud-based service, send the signed noncealong with the encrypted data blob to the new server, and establish thetrust between the management server and the new server upon successfulauthentication of the signed nonce and the encrypted data blob by thenew server.

Although shown as contiguous blocks, the machine readable instructionscan be stored in any order or configuration. For example, ifnon-transitory computer-readable media 506 and 606 may be a hard drive,the machine readable instructions can be stored in non-contiguous, oreven overlapping, sectors.

As used herein, a “processor” may include processor resources such as atleast one of a Central Processing Unit (CPU), a semiconductor-basedmicroprocessor, a Graphics Processing Unit (GPU), a Field-ProgrammableGate Array (FPGA) to retrieve and execute instructions, other electroniccircuitry suitable for the retrieval and execution instructions storedon a computer-readable medium, or a combination thereof. The processorfetches, decodes, and executes instructions stored on computer-readablemedium to perform the functionalities described below. In otherexamples, the functionalities of any of the instructions ofcomputer-readable media 506 and 606 may be implemented in the form ofelectronic circuitry, in the form of executable instructions encoded ona computer-readable storage medium, or a combination thereof.

As used herein, a “computer-readable medium” may be any electronic,magnetic, optical, or other physical storage apparatus to contain orstore information such as executable instructions, data, and the like.For example, any computer-readable storage medium described herein maybe any of Random Access Memory (RAM), volatile memory, non-volatilememory, flash memory, a storage drive (e.g., a hard drive), a solidstate drive, any type of storage disc (e.g., a compact disc, a DVD,etc.), and the like, or a combination thereof. Further, anycomputer-readable medium described herein may be non-transitory. Inexamples described herein, a computer-readable medium or media is partof an article (or article of manufacture). An article or article ofmanufacture may refer to any manufactured single component or multiplecomponents. The medium may be located either in the system executing thecomputer-readable instructions, or remote from but accessible to thesystem (e.g., via a computer network) for execution. In the example ofFIGS. 5 and 6, each of computer-readable media 506 and 606 may beimplemented by one computer-readable medium, or multiplecomputer-readable media.

In examples described herein, computing systems, such as managementserver, cloud-based service, and/or new server, may communicate witheach other via a network interface device. In examples described herein,a “network interface device” may be a hardware device to communicateover at least one computer network. In some examples, a networkinterface may be a Network Interface Card (NIC) or the like. As usedherein, a computer network may include, for example, a Local AreaNetwork (LAN), a Wireless Local Area Network (WLAN), a Virtual PrivateNetwork (VPN), the Internet, or the like, or a combination thereof. Insome examples, a computer network may include a telephone network (e.g.,a cellular telephone network).

In some examples, instructions may be part of an installation packagethat, when installed, may be executed by processors 504 and 604 toimplement the functionalities described herein in relation toinstructions. In such examples, computer-readable media 506 and 606 maybe a portable medium, such as a CD, DVD, or flash drive, or a memorymaintained by a server from which the installation package can bedownloaded and installed. In other examples, instructions may be part ofan application, applications, or component(s) already installed oncomputing system 502 and server 602 including processors 504 and 604,respectively. In such examples, computer-readable media 506 and 606 mayinclude memory such as a hard drive, solid state drive, or the like.

It may be noted that the above-described examples of the presentsolution is for the purpose of illustration only. Although the solutionhas been described in conjunction with a specific embodiment thereof,numerous modifications may be possible without materially departing fromthe teachings and advantages of the subject matter described herein.Other substitutions, modifications and changes may be made withoutdeparting from the spirit of the present solution. All of the featuresdisclosed in this specification (including any accompanying claims,abstract and drawings), and/or all of the steps of any method or processso disclosed, may be combined in any combination, except combinationswhere at least some of such features and/or steps are mutuallyexclusive.

The terms “include,” “have,” and variations thereof, as used herein,have the same meaning as the term “comprise” or appropriate variationthereof. Furthermore, the term “based on,” as used herein, means “basedat least in part on.” Thus, a feature that is described as based on somestimulus can be based on the stimulus or a combination of stimuliincluding the stimulus.

The present description has been shown and described with reference tothe foregoing examples. It is understood, however, that other forms,details, and examples can be made without departing from the spirit andscope of the present subject matter that is defined in the followingclaims.

What is claimed is:
 1. A system comprising: a network device; a newserver connected to the network device; and a management servercommunicatively connected to a cloud-based service and the networkdevice, wherein the management server includes a server deploymentengine to: discover the new server in the system using the networkdevice; obtain an encrypted data blob associated with the new serverfrom the cloud-based service; establish a trust, via a secure protocol,with the new server using the encrypted data blob; and deploy the newserver in the system upon establishing the trust with the new server. 2.The system of claim 1, wherein the server deployment engine is to:establish a trusted connection with the cloud-based service using atrusted certificate; and obtain the encrypted data blob associated withthe new server from the cloud-based service upon establishing thetrusted connection.
 3. The system of claim 1, wherein the serverdeployment engine is to: obtain an encrypted signed data blob from thecloud-based service using a unique identifier associated with the newserver, wherein the encrypted signed data blob comprises the encrypteddata blob signed by the cloud-based service; send the encrypted signeddata blob to the new server; and establish the trust, via the secureprotocol, with the new server upon authenticating the encrypted signeddata blob by the new server.
 4. The system of claim 3, wherein the newserver comprises an authentication engine to: receive the encryptedsigned data blob from the server deployment engine; verify signature ofthe encrypted signed data blob using a corresponding cloud-based servicepublic key shipped with the new server; decrypt the encrypted data blobusing a private key in the new server upon verifying the signature ofthe encrypted signed data blob; determine that the decrypted data blobincludes default password and device credentials associated with the newserver; and enable the server deployment engine to establish the trustwith the new server based on the determination.
 5. The system of claim1, wherein the server deployment engine is to deploy the new server inthe system based on pre-defined rules.
 6. The system of claim 1,comprising a cloud-based service to store or retrieve the encrypted datablob associated with new server, wherein the encrypted data blobcomprises a password and device credentials associated with the newserver, wherein the device credentials comprise a unique identifier, arandom number or a combination thereof.
 7. A method comprising:discovering a new server added to a data center via a network deviceconnected to the new server; establishing a trusted connection with acloud-based service using a trusted certificate; obtaining an encryptedsigned data blob associated with the new server from the cloud-basedservice upon establishing the trusted connection, wherein the encryptedsigned data blob comprises an encrypted data blob signed by thecloud-based service using a cloud-based service private key; sending theencrypted signed data blob to the new server; establishing a trust withthe new server upon authenticating the encrypted signed data blob by thenew server; and deploying the new server in the data center uponestablishing the trust with the new server.
 8. The method of claim 7,wherein establishing the trust with the new server upon authenticatingthe encrypted signed data blob by the new server comprises: receivingthe encrypted signed data blob from a management server by the newserver; verifying signature of the encrypted signed data blob using acorresponding cloud-based service public key shipped with the newserver; decrypting the encrypted data blob using a private key in thenew server upon verifying the signature of the encrypted signed datablob; determining that the decrypted data blob includes default passwordand device credentials associated with the new server; and establishingthe trust between the management server and the new server based on thedetermination.
 9. The method of claim 8, wherein, in establishing thetrust between the management server and the new server, communicationsbetween the management server and the new server are carried out usinglink layer discovery protocol (LLDP) packets via the network deviceconnecting the new server and the management server.
 10. The method ofclaim 7, wherein deploying the new server in the data center uponestablishing the trust with the new server comprises: sending a onetimepassword to the new server, wherein the onetime password is used tologin to the new server to set up the new server.
 11. The method ofclaim 7, wherein the encrypted data blob comprises a password and devicecredentials associated with the new server, wherein the devicecredentials comprise a unique identifier, a random number or acombination thereof.
 12. The method of claim 7, wherein obtaining theencrypted signed data blob associated with the new server comprises:obtaining the encrypted signed data blob associated with the new serverfrom the cloud-based service using a unique identifier associated withthe new server.
 13. A non-transitory machine-readable storage mediumcomprising instructions executable by a processor of a management serverto: receive a request to deploy a new server; establish a trustedconnection with a cloud-based service using a trusted certificate;obtain an encrypted signed data blob associated with the new server fromthe cloud-based service upon establishing the trusted connection,wherein the encrypted signed data blob comprises an encrypted data blobsigned by the cloud-based service, wherein the encrypted data blobcomprises a password and device credentials associated with the newserver; send the encrypted signed data blob to the new server; establisha trust with the new server based on successful authentication of theencrypted signed data blob by the new server; and send a onetimepassword to the new server upon establishing the trust with the newserver, wherein the onetime password is used to login and deploy the newserver.
 14. The non-transitory machine-readable storage medium of claim13, wherein the new server comprises memory storing instructions to:receive the encrypted signed data blob from the management server;verify signature of the encrypted signed data blob using a correspondingcloud-based service public key shipped with the new server; decrypt theencrypted data blob using a private key shipped with the new server uponverifying signature of the encrypted signed data blob; determine thatthe decrypted data blob includes default password and device credentialsassociated with the new server; and establish the trust between themanagement server and the new server based on the determination.
 15. Thenon-transitory machine-readable storage medium of claim 13, whereinestablishing the trust with the new server based on authentication ofthe encrypted signed data blob comprises: receive a nonce from the newserver in link layer discovery protocol (LLDP) packets, wherein thenonce comprises a random number; send the nonce to the cloud-basedservice; obtain a signed nonce along with the encrypted data blob fromthe cloud-based service; send the signed nonce along with the encrypteddata blob to the new server; and establish the trust between themanagement server and the new server upon successful authentication ofthe signed nonce and the encrypted signed data blob by the new server.